序号
测试级别
测试类型
文 档 审 查
代 码审查
代 码 走查
逻 辑 测 试
功 能 测 试
性 能 测 试
时 序 测试
接 口 测 试
强 度 测 试
余 量 测 试
安 全 性 测 试
边界测试
功 耗 分 析
1
单元测试
2
配置项测试
3
系统测试
注：“●”为该测试级别可含有该类测试类型，“一 ”为该测试级别不应含有该类测试类型。
本文是学习GB-T 33783-2017 可编程逻辑器件软件测试指南. 而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们
本标准规定了可编程逻辑器件软件测试的目的、内容、管理、级别、过程、类型和方法等要求。
本标准适用于可编程逻辑器件软件的测试。
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文
件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 8566—2007 信息技术 软件生成周期过程
GB/T 11457—2006 软件工程术语
GB/T 20158—2006 信息技术 软件生存周期过程 配置管理
GB/T 33781—2017 可编程逻辑器件软件开发通用要求
GB/T 33784—2017 可编程逻辑器件软件文档编制规范
GB/T 11457—2006 和 GB/T33781—2017
中界定的以及下列术语和定义适用于本文件。
3.1
可编程逻辑器件软件系统 programmable logic device
software system
相互间具有连接关系的可编程逻辑器件软件配置项集合。
3.2
工况 working condition
影响可编程逻辑器件时延的电压因素和温度因素。
3.3
典型工况 typical working condition
可编程逻辑器件工作时的额定电压、额定温度。
3.4
最大工况 maximal working condition
可编程逻辑器件工作时的最低电压、最高温度。
3.5
最小工况 minimum working condition
可编程逻辑器件工作时的最高电压、最低温度。
可编程逻辑器件软件测试的目的是：
a)
验证可编程逻辑器件软件是否满足合同或开发技术要求、系统/子系统设计文档、需求规格说
GB/T 33783—2017
明等所规定的要求；
b) 发现可编程逻辑器件软件错误；
c) 提供可编程逻辑器件软件产品质量评价的依据。
宜参考附录 A 和附录 B
规定，选择对应的测试方法，对可编程逻辑器件软件单元、配置项或系统的
功能要求、性能要求、时序要求、接口要求、强度要求、余量要求、安全性要求、边界要求和功耗要求等开
展测试。
软件测试宜由相对独立的人员进行。宜对测试过程中的测试活动和测试资源进行管理，其中测试
活动管理要求参见GB/T 8566—2007中7.1,测试资源管理要求参见GB/T 8566—2007
中7.5。
一般情况下，软件测试的人员配备见表1,一个人可承担多个角色的工作，
一个角色可由多个人
承担。
表 1 软件测试人员配备情况表
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试的准入准出条件如下：
a) 开始软件测试工作一般宜具备下列准入条件：
1) 具有测试合同(或项目计划);
2) 具有软件测试所需的各种文档；
GB/T 33783—2017
3) 所提交的被测软件受控；
4) 软件源代码正确通过编译或汇编。
b) 结束软件测试工作一般宜达到下列准出条件：
1) 已按要求完成了合同(或项目计划)所规定的软件测试任务；
2) 实际测试过程遵循了原定的软件测试计划和软件测试说明；
3) 客观、详细地记录了软件测试过程和软件测试中发现的所有问题；
4) 软件测试文档齐全、符合规范；
5) 软件测试的全过程自始至终在控制下进行；
6) 软件测试中的问题或异常有合理解释或正确有效的处理；
7) 软件测试工作通过测试评审；
8) 全部测试软件、被测软件、测试支持软件和评审结果已纳入配置管理。
宜按照软件配置管理的要求，将测试过程中产生的各种软件工作产品纳入配置管理。由开发组织
实施的软件测试，宜将测试工作产品纳入软件项目的配置管理；由独立测试组织实施的软件测试，宜建
立配置管理库，将被测对象和测试工作产品纳入配置管理。配置管理要求见GB/T
20158—2006。
在测试执行前，对测试计划和测试说明等进行评审，评审测试计划的合理性、测试用例的正确性、科
学性和覆盖充分性，以及测试环境是否齐全并符合技术要求等。评审的具体内容和要求宜包括：
a) 测试文档内容完整性、正确性和规范性；
b)
比较测试环境与真实运行的软件、硬件环境的差异，审查测试环境要求是否正确合理，满足测
试要求；
c) 测试项选择的完整性和合理性；
d) 测试用例的可行性、正确性和充分性。
在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的，主要对测试记录、测试
报告进行评审，评审的具体内容和要求宜包括：
a) 文档和记录内容完整性、正确性和规范性；
b) 测试环境是否符合测试要求；
c) 测试记录、测试数据及测试报告内容与实际测试过程和结果的一致性；
d) 实际测试过程与测试计划和测试说明的一致性；
e) 未测试项和新增测试项的合理性；
f) 测试结果的真实性和正确性；
g) 测试过程中出现异常处理的正确性。
单元测试的对象为可编程逻辑器件软件单元， 一般宜符合以下要求：
GB/T 33783—2017
a)
宜逐项测试设计说明等文档所规定的软件单元的所有功能、性能、接口和安全性与可靠性等
特性；
b)
软件单元的每个特性宜至少被一个正常测试用例和一个被认可的异常测试用例覆盖；
c) 测试用例的输入宜至少包含有效等价类值和无效等价类值；
d) 覆盖率宜达到测试充分性的要求，对未覆盖的情况进行分析；
e) 宜测试软件单元之间所有接口。
配置项测试的对象为可编程逻辑器件软件配置项， 一般宜符合以下要求：
a)
宜逐项测试需求规格说明等文档所规定配置项的所有功能、性能、时序、接口、余量和安全性与
可靠性等特性；
b)
配置项的每个特性宜至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；
c) 测试用例的输入宜至少包括有效等价类值和无效等价类值；
d) 覆盖率宜达到测试充分性的要求，对未覆盖的情况进行分析；
e) 在边界状态和异常状态运行条件下，宜测试配置项的功能和性能；
f)
宜按软件需求规格说明等文档的要求，对配置项的功能、性能等进行强度测试；
g)
对有恢复或重置功能需求的配置项，宜测试其恢复或重置功能，并且对每一类导致恢复或重置
的情况进行测试；
h) 必要时，宜对配置项的功耗情况进行分析。
系统测试的对象为完整的、集成的可编程逻辑器件软件系统，
一般宜符合以下要求：
a)
宜逐项测试合同或开发技术要求等文档所规定的功能、性能和安全性与可靠性等特性；
b)
系统的每个特性宜至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；
c) 测试用例的输入宜至少包括有效等价类值和无效等价类值；
d) 宜测试配置项之间及配置项与其他硬件之间的所有接口；
e) 宜测试系统输入/输出通道的吞吐能力和处理时间的余量；
f) 测试项宜实现对合同或开发技术要求相关需求的100%覆盖；
g) 宜在边界状态、异常状态的运行条件下测试系统的功能和性能；
h)
宜按合同或开发技术要求等文档的要求，对系统的功能、性能等进行强度测试；
i)
对有恢复或重置功能需求的系统，宜测试其恢复或重置功能，并且对每一类导致恢复或重置的
情况进行测试。
根据可编程逻辑器件软件合同或其他等效文件，以及可编程逻辑器件软件开发技术要求、软件需求
规格说明或设计说明等进行测试策划，形成测试计划，文档格式见 GB/T
33784—2017,一般宜符合以
下要求：
a) 测试需求分析：
1) 分析被测可编程逻辑器件软件，确定测试级别、被测对象及测试内容；
2)
宜依据开发技术要求、需求规格说明等文档分析被测软件的测试需求，确定所需测试类型
及要求并进行标识，宜分别确定每个测试对象所需测试类型及测试要求并进行标识，标识
GB/T 33783—2017
宜清晰、便于识别；
3)
宜根据被测软件的重要性、测试目标、约束条件和用户要求，确定测试类型的充分性要求；
4) 确定每个测试类型中的各个测试项及其优先级，并对测试项进行标识；
5) 确定每个测试类型中各个测试项的测试方法；
6)
确定每个测试项的测试终止要求，包括测试过程正常终止的条件和导致测试过程异常终
止的可能情况；
7)
宜建立测试项与开发技术要求、需求规格说明追踪关系，确保测试项100%覆盖软件
需求；
8) 分析和评价测试环境的有效性和差异性。
b) 测试过程的策划：
1) 确定测试策略，包括技术策略和管理策略；
2)
确定测试需要的技术，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技
术等；
3)
确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等；
4) 进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等；
5) 确定结束条件；
6) 确定被测软件的评价要求；
7) 确定测试活动的进度；
8)
确定需采集的度量，如测试需求度量、用例度量、风险度量、缺陷度量和工作量度量等，并
保存相宜的数据。
测试设计和实现过程宜依据测试计划，对最终分解的每个测试项，进行测试用例设计并说明测试用
例的设计方法， 一般宜符合以下要求：
a) 针对最终分解后的每个测试项，设计测试用例。
b) 确定测试用例的执行顺序。
c) 针对测试输入要求，设计测试数据，准备和验证所有的测试数据。
d) 形成测试说明，要求如下：
1) 确定测评项目名称和项目标识；
2) 确定测试用例名称、标识和所采用的测试方法；
3) 确定测试用例所依据的内容来源，并追踪到相应测试项标识；
4) 确定测试用例的初始化要求；
5) 确定测试用例的前提和约束；
6) 确定测试用例的输入，包括每个测试输入的名称、用途和具体内容；
7) 确定测试用例的期望测试结果；
8)
确定测试用例的测试结果评估准则，用以判断测试用例执行中产生的中间或最后结果是
否正确；
9) 确定实施测试用例的执行步骤；
10)确定测试用例的正常终止和异常终止条件。
e) 宜建立测试说明与测试计划的追踪关系，追踪到每个测试用例。
f)
依据测试用例的要求设计和实现测试环境，如仿真测试环境、实物测试环境等。
按测试计划和测试说明的内容和要求执行测试，填写测试的原始记录，
一般宜符合以下要求：
GB/T 33783—2017
a) 执行测试用例，人工或由测试环境自动判读测试结果。
b)
根据每个测试用例的期望测试结果、实际测试结果和评估准则等判定测试用例是否通过，当结
果有量值要求时，宜准确记录实际的量值。
c) 当测试用例不通过时，宜根据不同的缺陷类型宜采取相应的措施：
1)
记录测试工作的缺陷(包含测试用例、测试数据、执行步骤、测试环境等的缺陷),实施相应
的变更；
2) 在问题报告单中记录被测试软件的缺陷。
d) 当测试过程正常终止时，宜分析测试工作是否充分，是否需补充测试。
e)
当测试过程异常终止时，宜记录导致异常终止的条件、未完成的测试或未被修正的错误。
f)
形成测试记录，至少包括测试用例标识、测试结果描述(如仿真结果图、覆盖率信息图、逻辑等
效性检查结果图、静态时序分析结果图等)和发现的缺陷。
g) 建立问题报告单、测试记录与测试说明的追踪关系。
h)
必要时，可开展回归测试，宜对软件修改及影响域进行分析，新增、修改、删减或重用测试用例，
并进行测试。
根据合同或其他等效文件，以及开发技术要求、需求规格说明、设计说明、测试计划、测试说明、测试
记录等，对测试工作和被测软件进行分析和评价，形成测试报告，文档格式见
GB/T 33784—2017,一 般
宜包含以下内容：
a) 测试工作：
1) 描述测试范围、测试过程、测试类型、测试方法及测试结果；
2) 分析和评价测试充分性；
3) 描述测试环境的有效性和差异性；
4) 描述测试工作中问题的处理情况；
5) 总结测试计划和测试说明的变化情况及其原因；
6) 在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由；
7) 确定无法解决的测试事件，并说明不能解决的理由；
8) 说明测试工作遗留问题可能造成的影响和风险。
b) 被测软件：
1) 总结被测软件与开发技术要求、需求规格说明等文档的符合性及差异；
2) 对开发文档进行评价；
3) 说明被测试软件版本、开发文档版本；
4) 说明被测软件遗留问题；
5) 必要时，根据差异评价被测软件的设计和实现，并提出改进建议；
6) 总结测试中发现的被测软件问题，必要时，提出改进建议；
7) 必要时，宜指明测试环境和约束条件等对测试结果和软件运行的影响。
宜依据文档检查单对被测软件文档进行审查， 一般包括以下内容：
a) 审查文档齐全性；
b) 审查文档标识和签署的完整性；
GB/T 33783—2017
c) 审查文档内容的完备性、准确性、 一致性、可追踪性；
d) 审查文档格式的规范性。
宜依据代码检查单对被测软件进行审查， 一般包括以下内容：
a) 审查工程文件的完整性、 一致性；
b) 审查代码和设计的一致性；
c) 审查代码执行标准的情况；
d) 审查代码逻辑表达的正确性；
e) 审查代码结构的合理性；
f) 审查代码的可读性；
g) 审查约束文件的符合性。
宜根据代码逻辑查找被测软件缺陷， 一般包括以下内容：
a) 对至少一个完整的功能模块或完整的专题进行走查；
b) 人工检查程序逻辑，记录走查结果；
c) 必要时，可以画出结构图、状态迁移图和时序关系图等。
宜利用软件内部的逻辑结构及有关信息，设计或选择测试用例，对逻辑路径进行测试，检查软件状
态，确定实际状态是否与预期状态一致， 一般包括以下内容：
a) 语句覆盖；
b) 分支覆盖；
c) 条件覆盖；
d) 表达式覆盖；
e) 位翻转覆盖；
f) 状态机覆盖。
宜对需求规格说明等文档中规定的所有功能需求逐项进行测试，
一般包括以下内容：
a) 对存在边界值的功能项合法的以及非法的边界值进行测试；
b) 在配置项测试时对配置项控制流程的正确性、合理性等进行验证；
c)
功能的每个特性至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；
d)
如有必要，需对程序代码、逻辑综合后网表文件及布局布线后网表文件的逻辑一致性开展
检查。
宜对需求规格说明等文档中规定的各项性能进行测试， 一般包括以下内容：
a) 测试软件的时间指标；
b) 测试软件的精度指标；
c)
在典型工况、最大工况、最小工况(三种工况)下，测试软件的其他性能指标，如为完成功能所需
处理的数据量、为完成功能所需的运行时间、最大工作频率等。
GB/T 33783—2017
宜在三种工况下，对软件的时延、建立时间、保持时间等指标进行测试，
一般包括以下内容：
a) 测试建立、保持时间是否满足要求；
b) 测试时序控制信号相位、时延、电平宽度等是否满足要求；
c) 测试脉冲信号的频率、占空比等是否满足要求。
宜对需求规格说明等文档中规定的各项接口进行的测试， 一般包括以下内容：
a) 针对所有的外部接口进行测试，并检查接口实现的正确性；
b)
接口的每个特性至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；
c) 测试不同的接口数据、通信速率、错误类型等对软件功能及性能的影响。
宜在软件运行异常至发生故障的过程中，用于检验软件在扩展情况下可工作的临界点，
一般包括以
下内容：
a) 提供最大处理的信息量；
b) 提供数据处理能力的饱和实验指标；
c) 在错误状态下进行软件反应的测试；
d) 在规定的持续时间内，进行连续非中断的测试。
宜对被测软件的余量要求进行测试， 一般包括以下内容：
a) 经过布局布线后的软件的资源使用余量；
b) 经过布局布线后的软件的时钟余量；
c) 输入/输出及通道的吞吐能力余量；
d) 功能处理时间的余量。
宜对被测软件的安全性要求进行测试， 一般包括以下内容：
a) 对状态机可能出现的异常情况进行测试；
b) 测试抗状态翻转措施的有效性；
c) 测试防止危险状态措施的有效性和每个危险状态下的反应；
d) 测试用于提高安全性的结构、算法、容错、冗余等方案；
e) 测试的跨时钟域信号处理的有效性；
f) 进行边界内、边界外及边界结合部的测试；
g) 进行最坏情况配置下的最小输入和最大输入数据率的测试；
h) 测试工作模式切换和多机替换的正确性和连续性。
宜对软件处在边界或端点情况下的运行状态进行测试， 一般包括以下内容：
a) 对软件输入域或输出域的边界或端点进行测试；
b) 对功能界限的边界或端点进行测试；
GB/T 33783—2017
c) 对性能界限的边界或端点进行测试；
d) 对状态转换的边界或端点进行测试。
宜对被测软件运行时所消耗的功率进行分析， 一般包括以下内容：
a)
在额定工作频率、工作电压、环境温度、输入信号频率、输出负载电容和驱动电流、内部信号的
翻转率等约束条件下，进行功耗分析；
b) 在额定运行时间条件下，进行功耗分析。
设计检查是采用人工(包含工具辅助)的方法，对开发文档及工程文件等进行测试，设计检查宜包含
以下工作内容：
a) 检查文档的正确性、准确性和一致性；
b)
检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性
以及代码的可读性；
c)
检查被测软件的外部接口与其外围接口芯片的接口符合性，被测软件外部接口相关代码在逻
辑和时序方面处理方式的合理性；
d)
检查内部模块之间接口信号的一致性，内部模块之间接口信号相关代码在逻辑和时序方面处
理方式的合理性；
e) 检查约束文件的正确性、 一致性。
功能仿真是在不包含信号传输延时信息的条件下，用仿真方法验证设计的逻辑功能是否正确的过
程。功能仿真宜包含如下工作内容：
a)
依据测试用例的要求，建立功能仿真环境，编制仿真测试激励向量，宜满足被测软件外部输入
的功能、性能、时序、接口等要求；
b)
在仿真工具中开展功能仿真工作，人工或自动检测仿真结果，并依据判定准则确定测试用例是
否通过；
c)
统计语句覆盖率和分支覆盖率等覆盖率信息，对未覆盖的情况进行影响域分析。
门级仿真是针对逻辑综合后网表文件开展的仿真测试，宜包含以下工作内容：
a)
依据测试用例的要求，建立门级仿真环境，编制仿真激励测试向量，针对逻辑综合后的网表文
件开展门级仿真；
b)
在仿真工具中开展门级仿真工作，人工或自动检测仿真结果，并依据判定准则确定测试用例是
否通过。
时序仿真是针对布局布线之后的网表文件和标准延时格式文件开展的仿真测试，宜包含以下工作
内容：
a) 依据测试用例的要求，建立时序仿真环境，编制仿真激励测试向量集；
GB/T 33783—2017
b)
在仿真工具中开展时序仿真工作，人工或自动检测仿真结果，并依据判定准则确定测试用例是
否通过。
依据测试用例的要求，针对逻辑综合或布局布线后的网表文件和标准延时格式文件开展静态时序
分析，宜包含以下工作内容：
a) 定义时序约束；
b)
在静态时序分析工具中加载被测文件，被测文件包括：逻辑综合或布局布线后的网表文件、标
准延时格式文件、时序约束文件、相关库文件；
c) 分别在三种工况下开展静态时序分析；
d) 对未覆盖情况进行分析和说明；
e)
人工对时序分析得到的信息进行二次分析，对时序违反情况进行问题追踪和定位。
依据测试用例的要求，对设计代码、逻辑综合后的网表文件及布局布线后的网表文件开展逻辑等效
性检查，宜包含以下工作内容：
a) 在逻辑等效性检查工具中加载被测文件；
b) 在逻辑等效性检查工具中人工对尚未匹配的比对点进行分析和匹配；
c) 执行逻辑等效性检查；
d) 人工对分析结果进行二次分析，对不等价点进行问题追踪和定位。
实物测试是将配置文件加载到真实的目标板中或经过认可的目标板中，向被测试可编程逻辑器件
施加激励，确认输出是否正确的过程，宜包含以下工作内容：
a)
依据测试用例的要求，在实际运行条件下，对软件实现的功能和性能指标进行测试；
b) 在真实的硬件环境中，对被测软件施加测试激励，记录测试结果。
GB/T 33783—2017
(资料性附录)
可编程逻辑器件软件测试级别与测试类型对应关系
可编程逻辑器件软件测试级别与测试类型对应关系参见表A.1。
表 A.1 可编程逻辑器件软件测试级别与测试类型对应关系表
|
|
|
||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|||||||||||||
|
|
|||||||||||||
|
|
|||||||||||||
|
||||||||||||||
GB/T 33783—2017
(资料性附录)
可编程逻辑器件软件测试类型与测试方法对应关系
可编程逻辑器件软件测试类型与测试方法对应关系参见表B.1。
表 B.1 可编程逻辑器件软件测试类型与测试方法对应关系表
|
|
|
||||||
|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
||||||||
更多内容 可以 GB-T 33783-2017 可编程逻辑器件软件测试指南. 进一步学习